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SP  Summary  (with  Authority  Mode) 

Timothy  E.  Levin 


A.  SP  modes,  modules  and  processing  verification 

■  A  processor  mode  is  entered  via  a  corresponding  SP  “begin”  instruction 

■  SP  is  in  a  mode  IFF  SP  is  executing  the  corresponding  type  of  module 

■  Module  instructions  checked  via  inline  hashes  and  corresponding  key: 


Instruction 

Module 

Hash  Key 

BEGIN_A-CEM 

A-TSM 

DRK 

BEGINJJ-CEM 

U-TSM 

DMK 

BEGIN_CIC 

I-TSM 

DRK 

■  On  return  from  an  interrupt,  InterruptHash  of  previous  registers  (uses  DRK/DMK), 
and  InterruptAddr  (previous  instruction)  are  checked;  both  values  can  be  saved 
and  restored  by  ring  -2  to  multiplex  modes.  Separate  hash  and  addr  values  may  be 
provided  for  each  mode  (A-TSM  is  not  yet  decided). 

B.  SP-resident  master  secrets  -  arbitrary  values,  2-wordsi  each 

■  UserMasterKey  -  UMK  -  read  by  UTSM;  written  only  by  lowest  ring.  Volatile 
storage 

■  DeviceRootKey  -  DRK  -  stored  by  “secure  bios,”  and  locked  until  the  next  power 
cycle.2  Non-volatile  storage. 

■  StorageRootHash-  SRH  -  read  and  written  by  ATSM.  Non-volatile  storage. 

■  DeviceMasterKey  -  DMK  -  stored  by  “secure  bios,”  and  locked  until  the  next  power 

2 

cycle.  Non-volatile  storage. 

C.  SP  transformation  functions 

■  Derive  (  )  -  2-word  to  2-word  crypto-hash  function  available  to  ATSM 

i.  Based  on  DRK 

■  CEM  Load /  Store  ()- Available  to  ATSM/UTSM 

i.  Encrypt  &  hash  one  word  on  exit  from  processor  cache-  decrypt  and  check  hash 
on  load 

ii.  Based  on  DRK/DMK 


Figure  1.  Authority  Mode  Features 


1  Word  size  depends  on  the  architecture:  e.g.,  32  or  64  bits,  and  whether  multiple  load  instructions  are  to  be 
used. 

2  Restriction  to  lowest  ring  may  also  figure  into  DRK  and  DMK  modifications. 
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Table  2.  SP  Instructions  and  Parameters 


Instruction 

Description 

Existing  Startnn  SP  Instructions  tat  secure  bootuo  -  secure  BIOS  only) 

GRtoDMKRi,Rj,  (DMK) 

DMK  =  R;  Rj;  Sets  Device  Master  Key  register  from  GRs.  (Only  in  Secure 
bootup  BIOS  -  before  any  ring  protection  is  established ) 

Existing  SP  Instructions 

BEGIN  CEM 

Enter  CEM  for  next  instruction.  Sets  CEM  mode  for  next  instruction. 

END.CEM 
(onlv  in  CEM  mode) 

End  CEM  for  next  instruction.  Clears  CEM  mode  for  next  instruction 

UMKtoGR  (UMK).  R;.R; 

(only  in  CEM  mode) 

Ri  |R2  =  UMK  Reads  User  Master  Key  register  into  GRs. 

SECURE  STORE  Ri.  displ 
R: 

(only  in  CEM  mode) 

M[Ri  +  displ]  =  Re;  Secure  store  from  Re  to  memory  Sets  SecureData  cache  tag 
bits  in  on-chip  caches. 

SECURE  LOAD  Ri,  displ.  R 
(only  in  CEM  mode) 

Re  =  M[Ri  +  displ];  Secure  load  to  Re  from  memory.  If  hit  m  on-chip  LI  Data 
cache  or  on-chip  L2  cache,  checks  that  SecureData  tag  bit  is  set  for  cache  line,  if 
not,  evict  and  treat  as  a  miss.  If  nnss  in  on-chip  caches,  activate  decryption  and 
validation  on  fetching  cache  line  from  memory';  raise  exception  if  invalid. 

New  Instructions  to  Enable  Virtualization  of  SP  (Ring  -2  ONLY.  non-CEM) 

Save  SPregs 

(Ring  -2  only.  non-C'EM) 

Copies  SP.inthash,  SP.retaddr  and  SP.status  registers  to  secure  space  accessible 
ONLYtoLPSKat  Ring -2. 

Clears  SP.inthash  and  SP.retaddr  addresses,  and  sets  SP.stahis  appropriately. 

Done  by  LPSK  only  when  LPSK  switches  between  VMs. 

Restore  SPregs 

(Ring  -2  only,  non-CEM) 

Restores  SP.inthash.  SP  retaddr  and  SP.status  registers  from  secure  space  for 
this  VM  accessible  ONLY  to  LPSK  at  Ring  -2. 

Done  by  LPSK  only  when  LPSK  switches  between  VMs. 

Table  3.  Authority  Mode  Instructions  and  Parameters 


Instruction 

Operation 

Description 

Authority  Mode  Instructions  (new) 

GR-TO.DAK  R1K2.IDAK) 

DAK  =  R1||R2 

Sets  Device  Anestauon  Key  register  from  GRs. 

DAK.LOCK  (DAK-LodC) 

DAK_Lock  =  1 

Sets  DAK_Lock  register  to  1.  disabling  GR_TO_DAK  instruction. 

GR-TO.LSH  R1.R2.  (LSH) 

LSH  =  R1||R2 

Sets  Local  Storage  Hash  register  from  GRs. 

LSH -TO-GR  (LSH).  R1.R2 

R1||R2  =  LSH 

Reads  the  Local  Storage  Hash  register  into  GRs 

DAK-DERIYE  R2.R2.R3.fR4) 

R3||R4  =  HAE4Cd.4k(R1||R2) 

Derives  a  key  from  die  DAK.  RI ||R2  is  die  nonce.  R3||(R4)  is  the  destination. 
(R4  is  implied  even  register  with  R3.) 

Common  Instructions  (leveraged  from  SP) 

BEGIN  jCEM 

CENLStatus  =  01 

Enter  CEM  for  next  mstniction. 

ENDjCEM 

CEM_Status  =  00 

End  CEM  for  nest  instruction. 

CEM -STORE  RI.  displ.  R2 

M[R1  +  displ]  =  R2 

Secure  store  from  GR  to  memory. 

CEM -LOAD  RI.  displ.  R2 

R2  =  M[R1  +  displ] 

Secure  load  to  GR  from  memory 

User  Mode  Instructions  m  SP  (discarded) 

GR-TO-DMK  RJ.R2.  (DMK) 

DMK  =  R1||R2 

Sets  Device  Master  Key  register  from  GRs. 

UMK-TO.GR  (UMK),  R1J(2 

RI  ||R2  =  UMK 

Reads  User  Master  Key'  register  into  GRs. 

Note  that  Table  3  uses  obsolete  names  “Local  Storage  Hash”  (SRH)  and  “DAK,  which 
have  been  changed  to  “Storage  Root  Hash”  (SRH),  and  DRK,  respectively. 
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Figure  1.  SP  State  Diagram  (User  Mode;  Auth  Mode  not  yet  clear) 


Table  4.  SP  Internal  Transformations  (User  and  Authority  Mode) 


Instruction 

Prerequisite 

State 

SP  actions 

Post  State 

Required 

Post¬ 

processing 

Description 

Request  for 
execution 
context 
change3 

Active_CEM 

-  Encrypt  registers  in  place 

-  Store  hash4  of  concatenated, 
encrypted  registers  to 
CEM.IntHash 

-  Store  PC  to  CEM.RetAddr 

-  Load  and  process  interrupt 
vector 

Interrupted 

CEM 

Software 
indicated  by 
interrupt 
vector  saves 

PC  and  GP 
registers 

Preserves 

CEM  state  on 
context  switch 
to  non-TSM 
code 

Request  for 
execution 
context 
change5 

-  Interrupted 

CEM 

-  Previous  PC 
and  GP  registers 
loaded  by 
software 

—  If  PC  matches 

CEM.RetAddr6  then  ( 

—  if  hash  of  GP  registers 
matches  CEM.IntHash  then  ( 

—  Decrypt  registers  in  place; 

—  process  PC)) 

Active_  CEM 

None 

Restores  CEM 

state  on  return 
from  non- 
TSM  code 

3  HW  interrupt  or  software  exception 

4 IV  for  the  register  encryption  will  likely  be  stored  with  the  hash. 

3  Any  HW  Jump  or  return  from  interrupt 

6  SP  designers  intend  to  introduce  a  feature  to  prevent  accidental  return  to  the  PC  address  from  a  different 
address  space,  which  could  be  handled  in  a  few  different  ways,  depending  on  OS  support.  If  hash  check 
fails,  SP  will  raise  an  exception. 
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